feat(signals): add SignalStoreFeatureType - #5186

We have something similar in our project except we have a second generic parameter where we can specify a subset of keys to depend on which helps limit the setup in our feature tests.

From memory it went something like this

type StoreFeatureResultKeys<T extends StoreFeatureResult> = keyof T['state'] | keyof T['props'] | keyof T['methods'];

type ExtractedStoreFeature<Feature extends (...params: never[]) => unknown> =
  ReturnType<Feature> extends SignalStoreFeature<infer Input, infer Output>
    ? Input & Output
    : never;

export type SignalStoreFeatureType<
  Feature extends (...params: never[]) => unknown,
  Keys extends StoreFeatureResultKeys<ExtractedStoreFeature<Feature>> = StoreFeatureResultKeys<ExtractedStoreFeature<Feature>>
> = {
  state: Pick<ExtractedStoreFeature<Feature>>['state'], Extract<Keys, keyof ExtractedStoreFeature<Feature>>['state']>>,
  props: Pick<ExtractedStoreFeature<Feature>>['props'], Extract<Keys, keyof ExtractedStoreFeature<Feature>>['props']>>,
  methods: Pick<ExtractedStoreFeature<Feature>>['methods'], Extract<Keys, keyof ExtractedStoreFeature<Feature>>['methods']>>,
};

// to depend on an entire feature
type<SignalStoreFeatureType<withSomeFeature>>()

// to depend on a subset of the feature
type<SignalStoreFeatureType<withSomeFeature, 'stateA' | 'methodB'>>()

@martin-the-geek, but why would you want that?

I see SignalStoreFeatureType is a type for a specific feature. If you want a more generic one that could be implemented by multiple signalStoreFeature types, then I understand the motivation behind your approach. But even then, I would write a generic type manually, meaning I would not like to depend on an existing one.

I just don't know if we are overcomplicating things here.

@rainerhahnekamp Our motivation for having a convenience type to identify a subset of a feature is to narrow the dependencies of another feature to limit the impacts to our feature tests.

If feature A depends on only a few signals from feature B but feature B has dozens, when testing feature A we only have to add the few bits to our test store that feature A depends on. Also, if in the future feature B adds some elements that are irrelevant to feature A, we don't have to update feature A's tests to include the new elements. Problem gets worse if feature B depends on feature C, etc.

Sure, I guess we just keep the key limiting type custom to our app, but it might be useful for others.

@markostanimirovic, could please re-check?